Folks, you may not realize it, but the RSADSI/PKP concession to allow a freeware PGP in the USA is BIG TIME GOOD NEWS! To induce a small incompatibility with a downlevel version of PGP with several bugs in it is a small annoyance by comparison.
#define VERSION_BYTE_OLD 2 /* PGP2 */
#define VERSION_BYTE_KLUDGE 3
...
boolean legal_kludge;
int version_byte = VERSION_BYTE_OLD;
...
/* Turn on incompatibility as of 1 September 1994 (GMT) */
legal_kludge = (get_timestamp(NULL) >= 0x2e651980);
...
if (legal_kludge)
version_byte = VERSION_BYTE_KLUDGE;
Although a method for disarming the time bomb is obvious to the casual C
programmer, disabling this feature invalidates the RSA license to use the
program, and really doesn't gain you much for reasons that will become
obvious below.
Format
generated Formats
before/after understood
Version 1 Sep 94 (all times)
- ---------------------------- ----- ---- -----------
2.3 2 2 2
2.3a 2 2 2
Amiga 2.3a.4 2 2 2,3
Viacrypt 2.4 2 2 2
2.6ui 2 2 2,3
MIT 2.6 2 3 2,3
Viacrypt 2.7, pkcs_compat=1 2 3 2,3
Viacrypt 2.7, pkcs_compat=2 2 2 2,3
Viacrypt 2.7, pkcs_compat=3 3 3 2,3
(Not mentioned above is MIT PGP 2.5, which was a buggy beta, nor several
other versions that are outside the mainstream PGP project).
If you are using one of the versions above that cannot understand version byte 3 messages, you should upgrade to one that does. The upgrade from Viacrypt PGP 2.4 to Viacrypt PGP 2.7 is only US$10, and also provides several other enhancements.
As you can see, people with downlevel versions of PGP will not be able to read all PGP messages directed at them, nor will they be able to verify all of the signed messages they might wish to verify.
It is also worth noting that none of the new versions have any trouble reading the old format messages.
PGP 2.3a, running on some platforms (but not others), use to be able to generate and use 1264 bit keys. In addition, some people have hacked their own copies of PGP to generate and use longer keys (up to 8192 bits or some such crazy number). Distribution of these hacked versions under the "Pretty Good Privacy" trademarked name is not recommended, since it upsets the trade mark owner (Philip Zimmermann) and interferes with some of his long term plans to support longer keys in a more organized fashion.
First, there is the minor problem that RSAREF and BSAFE (which are tied to the RSA patent license for the freeware and some commercial versions of PGP) have a key length limit of 1024 bits. Changing this involves negotiations with RSADSI/PKP, and could take some time. Second, allowing longer key sizes could create a Tower of Babel problem of incompatible PGP versions, since not all versions could handle these long keys. Third, the implementation of longer keys needs to be done in an orderly manner such that all mainstream PGP versions (Viacrypt, MIT freeware, BSAFE-based commercial, and possibly a non-USA variant) are first upgraded to accept, but not generate, the longer keys. After all PGP users can accept the longer keys, then PGP versions can start generating the longer keys with no interruption in service.
It still makes sense to have a length limit for compatibility reasons. I have asked Philip Zimmermann to increase that to at least 4096 bits when he can, and I think that he will do that in an orderly manner if there isn't too much in the way of hassles with RSAREF and BSAFE licensing.
If this isn't secure enough for you, shift to conventional encryption and manual (direct person-to-person) key exchange, making sure that your keys have at least 128 bits of entropy. This can be done with pgp -c or another private key encryption program called dlock that has the virtues of (1) NO patent problems, and (2) very strong encryption. (DLOCK is not nearly as user friendly as PGP, but what do you want for free?)
Although this is annoying if you have a really old key that has lots of old signatures on it, the fact is that the older the key, the more likely someone has captured both it and the passphrase used to protect it. Therefore, I strongly recommend generating a new key and getting at least one other person to sign it.
Fixed a bug with the -z
When using -c, the IV is generated properly now, and the randseed.bin postwash is done. (This bug could have resulted in the same ciphertext being generated for the same plaintext, if the same passphrase is used.)
Memory allocated with halloc() is now freed with hfree() in ztrees.c and zdeflate.c. (MS-DOS only.)
The decompression code now detects end of input reliably, fixing a bug that used to have it produce infinite amounts of output on come corrputed input. Decompression has also been sped up.
PGP -m won't try to write its final output to the current directory. This makes it less efficent if you want to save the text to a file, but more secure if you don't.
If the line
comment=
PGP now enables clearsig by default. If you sign and ascii-armor a text file, and do not encrypt it, it is clearsigned unless you ask for this not to be done.
The now enables textmode. Textmode detects non-text files and automatically turns itself off, so it's quite safe to leave on all the time. If you haven't got these defaults yourself, you might want to enable them.
All prompts and progress messages are now printed to stderr, to make them easier to find and ensure they don't get confused with data on standard output such as pgp -m output.
PGP now wipes temp files (and files wiped with pgp -w) with pseudo-random data in an attempt to force disk compressors to overwrite as much data as possible.
On Unix, if the directory /usr/local/lib/pgp exists, it is searched fror help files, language translations, and the PGP documentation. On VMS, the equivalent is PGP$LIBRARY:. (This is PGP_SYSTEM_DIR, defined in fileio.h, if you need to change it for your site.)
Also, it is searched for a default global config.txt. This file may be overridden by a local config.txt, and it may not set pubring, secring, randseed or myname (which should be strictly personal)
The normal help files (pgp -h) are pgp.hlp or
On Unix systems, $PGPPATH defaults to $HOME/.pgp.
PGP used to get confused if you had a keyring containing signatures from you, but not your public key. (PGP can't use the signatures in this case. Only signatures from keys in the keyring are counted.) PGP still can't use the signatures, but prints better warning messages. Also, adding a key on your secret key ring to your public keyring now asks if the key should be considered ultimately-trusted. Prviously, you had to run pgp -ke to force this check, which was non-obvious.
On Unix, PGP now figures out the resolution of the system clock at run time for the purpose of computing the amount of entropy in keystroke timings. This means that on many Unix machines, less typing should be required to generate keys. (SunOS and Linux especially.)
The small prime table used in generating keys has been enlarged, which should speed up key generation somewhat.
There was a bug in PGP 2.3a (and, in fact in 2.4 and dating back to 1.0!) when generating primes 2 bits over a multiple of the unit size (16 bits on PC's, 32 bits on most larger computers), if the processor doesn't deal with expressions like "1<<32" A KEY PRODUCING
At the request of Windows programmers, the PSTR() macro used to translate string has been renamed to LANG().
The random-number code has been *thoroughly* cleaned up. So has the IDEA code and the MD5 code. The MD5 code was developed from scratch and is available for public use.
Versions prior to 2.6 would not permit a new signature to be added to a key if there was an already existing signature from the same signer. Starting with version 2.6 newer signatures will override older ones *as long as the newer signature verifies*. This change is important because many keys have signatures on them that were created by PGP version 2.2 or earlier. These signatures can not be verified by PGP 2.5 or higher. Owners of keys with these obsolete signatures should attempt to gather new signatures and add them to their key.
On the other hand, if you are outside of the USA and Canada, you should be careful not to offend the U. S. Department of State, Office of Defense Trade Controls, by exporting MIT PGP 2.6 from the USA or Canada. I suppose that you wouldn't break U. S. law if you got a copy of MIT PGP 2.6 that someone else exported, or you could get a copy of the PGP 2.6ui (that originated in Great Britain) if you don't care about the enhancements listed above, or if you want to be able to use 1264-bit keys. Note that if you use MIT PGP 2.6 in most countries, you are still bound by the RSAREF license because of the copyright law, and you are still limited in some countries to noncommercial use of PGP by the IDEA patent (unless you get a license from ETH Zurich).
ftp://net-dist.mit.edu/pub/PGP/mitlicen.txt ftp://ftp.csn.net/mpj/README.MPJ ftp://ftp.wimsey.bc.ca/pub/crypto/software/README ftp://ftp.informatik.uni-hamburg.de/pub/virus/crypt/pgp/Look for the files pgp26.zip, pgp26src.zip, and pgp26src.tar.gz.
BBS:
Colorado Catacombs BBS 303-772-1062 (free -- log in with your name) Hieroglyphics Voodoo Machine 303-443-2457 (log in as VOO DOO, password NEW)
Download PGP26.ZIP, and for source, PGP26SRC.ZIP.
Compuserve: Use IBMFF to look for PGP26.ZIP and PGP26S.ZIP.
For a longer list, see the daily and montly postings on alt.security.pgp, or get ftp://ftp.csn.net/mpj/getpgp.asc
DON'T SET PGPPASS when editing your keys, because if you do, and if you don't change your pass phrase, the key is lost. (If this happens, rename your backup keyring files to the primary files before you do anything else).
These bugs have been fixed in the master source code, and will be corrected in the next release of MIT PGP.
If you have enhancements and suggestions for the PGP team, I suggest you coordinate with them so that your ideas can be integrated with the main PGP project.
Philip Zimmermann defense fund c/o Philip Dubois 2305 Broadway Boulder, Colorado 80304 USA